1. Field of the Invention
The present invention relates to a software debugger for debugging a program to be executed on a microcomputer, and a software development support system using the same; more particularly, the invention relates to a method of displaying the executing process of a microcomputer program having conditional execution instructions.
2. Description of the Related Art
With recent advances in electronic technology, increasing numbers of consumer appliances such as household electrical appliances have come to be equipped with built-in microcomputers, and the development of appliances entailing program development has become widespread.
Furthermore, with increasing functionality of household electrical appliances, high performance microcomputers having conditional execution instructions for faster program execution have come to be used.
In the development of a program, the program developer debugs the program by using a debugger and checking whether the developed program is functioning as designed. In debugging, it has been practiced to check the operation of the program by using debugger functions such as a step execution function, which steps through the program by executing one instruction at a time, and a trace function, which displays the sequence of program execution results.
FIG. 26 shows the configuration of a software development support system according to the prior art. Reference numeral 201 is a C source program, using which the software developer implements an application system being developed. Reference numeral 202 is a compiler, which takes the C source program 201 as an input, and outputs an object file 203 containing debugging information and microcomputer executable code used in the application system being developed. Reference numeral 204 is a debugger, which takes the object file 203 as an input, accepts commands from the software developer through a user interface, and performs debugging by checking the operation of the program being debugged.
The operation of the debugger 204 of the prior art will be described below. FIG. 27 shows a functional block diagram of the debugger 204.
Reference numeral 301 is a debugger processing section, which processes input/output operations, such as an input of a debugger command from the software developer as the user and the display or output of information for presentation to the user, and which performs processing in response to the debugger command thus input.
Reference numeral 302 is an execution target environment on which the program of the object file 203 is executed, and which is, for example, a microcomputer simulator implemented on a computer. Alternatively, the execution target environment may be implemented using an evaluation board on which the target microcomputer or a memory is mounted. The debugger processing section 301 realizes the debugging functions by controlling the execution target environment 302.
Reference numeral 303 is object code information which is the information stored in the debugger 204 by reading therein the object file 203, i.e., the program to be debugged, in accordance with an instruction from the user.
Reference numeral 304 is the debugging information containing various kinds of information necessary for debugging. This information is stored in the object file 203, and is read into the debugger. The contents include, for example, information for associating symbols such as function names and variable names with addresses, line number information for associating addresses with source lines in the C language program, and location information indicating the resource, such as a register or a memory, to which each variable is assigned.
Reference numeral 305 is instruction type information which is the information for associating instruction code with an instruction type, and includes information about mnemonic character strings in assemble form. By referring to this information, disassembling can be achieved from a memory value which is an instruction code on a memory.
Reference numeral 306 is trace data information in which trace frame data for outputting a trace is stored.
FIG. 28 shows a process flow of the prior art debugger. When the debugger 204 is activated, initialization is performed in step S401 to initialize the working memory of the debugger, draw a display window, etc.
Next, in step S402, a debugger command is accepted from the user. Here, the user enters a command for reading the object code of the program to be debugged or a command necessary for debugging, such as a program execution start command, a breakpoint setup command, or a memory dump command.
Next, in step S403, the entered command is interpreted, and in step S404, processing is performed for the entered command. The method of command execution is well known in the art and will be not described in detail here.
Next, in step S405, the debugger display is updated. The display update process includes, for example, updating the display contents of the code display window so as to display the codes before and after the address at which the program execution is caused to halt, and updating the display contents of the memory window so as to reflect changes in memory contents.
When a terminate command is entered in step S404, the terminating process, such as freeing the debugger working area and cutting the connection to the execution target environment, is performed in step S406.
FIG. 29 shows the process flow of the display update process in step S405. In the display update process, necessary processing is performed whenever there arises a need to update the display.
In step S2801, the execution state of the program being debugged is examined on the execution target environment, and if the execution is halted, the process proceeds to step S2802. If the execution of the program is not halted, but is continuing, the process is terminated since there is no need to update the display. On the other hand, if the execution is halted, the following steps are carried out to produce a display indicating to the program developer at which point in the program being debugged the execution is caused to halt.
In step S2802, the halt address of the program being debugged is acquired. That is, the register value of the program counter (PC) of the microcomputer on the execution target environment 302 is acquired.
Next, in step S2803, instruction code at the halt address acquired in step S2802 is read from the object code information 303 stored in the debugger.
In step S2804, the instruction code is disassembled to obtain an assemble line character string corresponding to the instruction code. The disassembling is done by referring to the instruction type information 305 managed in the debugger.
Next, in step S2805, the obtained assemble line character string is displayed in reverse video on the screen, and the line previously displayed in reverse video is now displayed in normal video.
Finally, in step S2806, the display of memory contents, etc., other than the instruction code display, is updated.
In the thus configured debugger, when the program developer enters, for example, a step execution command consecutively, program instructions being executed are sequentially displayed in reverse video, and the developer can thus debug the program while viewing the executing process of the program being debugged.
In “Software Trace Generation Method and Apparatus” trace to display the executing process of a program, executed instructions are displayed in different colors according to the order of execution, thus presenting the executing process of the program in an easy-to-view form.
However, in a microcomputer having conditional execution instructions, conditional execution traditionally implemented with a plurality of instructions can be implemented with one conditional execution instruction. As a result, traditionally, it has been possible to check the program executing process by tracking the instructions as they are executed, but in the case of conditional execution instructions, there arises the problem that by just tracking the executed instructions only, it is difficult to check the executing process.
A method of displaying the executing process in the prior art debugger will be described below by dealing with a program using a conditional execution instruction.
FIG. 5 shows a portion of a C language program to be debugged. Here, “01:”, “02:”, etc. are line numbers shown for purposes of explanation. In this program, the instruction on line 02 or 04 is executed according to the value of a variable “a” in the conditional statement.
FIG. 6 shows the result of assembling the C language program into microcomputer instruction code having a conditional execution instruction. Here, “0x400:”, “0x404:”, etc. indicate the addresses at which instructions are placed. In this example, the if-else condition execution structure in the C language is implemented using a conditional execution instruction.
At address 0x400, the value of register Ra is compared with 10, and the result is placed into flag c0. At address 0x404, if the flag c0 is true, the square of the value of the register Ra is transferred into register Rb. If the flag c0 is false, the instruction does nothing.
At address 0x408, if the flag c0 is false, the contents of register Rc are transferred into the register Rb. If the flag c0 is true, nothing is done. The sequence of instructions from address 0x400 to address 0x408 in FIG. 6 corresponds to the logic structure described by the if-else statement from line 01 to line 05 in FIG. 5.
A description will be given below for the case where the user, using the prior art debugger, checks the operation of the above C language program from address 0x400 to address 0x408 in a step execution mode.
It is assumed here that the execution of the program being debugged is halted at address 0x400. In this case, the assemble line at the halt address 0x400 is displayed in reverse video on the code display screen, as shown in FIG. 30A.
The user enters a step execute command in step S402.
In step S403, the entered command is interpreted, and necessary information, such as the information indicating that the type of the command is step execution, is extracted.
In step S404, step execution is performed based on the information extracted in step S403. The step execution is accomplished by performing control so that the execution target environment 302, a microcomputer simulator, executes one instruction. As a result, one instruction in the program being debugged is executed from the halt address on the execution target environment 302, and then the execution halts.
To update the display in step S405, the process proceeds to step S2801.
In step S2801, it is determined whether the execution is halted or not. Since the execution is halted, the process proceeds to step S2802.
In step S2802, the halt address is acquired by referring to the program counter (PC) value of the microcomputer simulator which is the execution target environment 302. In this case, 0x404 is obtained as the halt address.
Next, in step S2803, the instruction code at the halt address 0x404 is read from the object code information 303, and in step S2804, the instruction code is disassembled by referring to the instruction type information 305, to obtain an assemble line “(c0) mul Ra, Ra, Rb” as the resulting character string.
In step S2805, the display is updated to display the assemble line “(c0) mul Ra, Ra, Rb” in reverse video. At the same time, the assemble line previously displayed in reverse video is displayed in normal video. An example of the resulting display is shown in FIG. 30B.
The step execution is repeated in the same manner. Examples of the resulting displays are shown in FIGS. 30C and 30D.
The executing process of the program can be checked by viewing the assemble lines being sequentially displayed in reverse video. However, it is difficult to check if the processing “mul Ra, Ra, Rb” specified by the instruction at address 0x404 and the processing “mov Rc, Rb” specified by the instruction at address 0x408 have actually been executed.
The resulting problem is that it is difficult to check the program logic described by the if-else control structure.
The same problem occurs when displaying the results of a trace.